SIEM で Windows Event Log の不審なイベントを検知する

SIEMを使ったユースケース紹介のブログとなります。Windows Event Logの消去やロギングサービス停止の攻撃を検知・分析します。

#セキュリティ

#SIEM

#ログ分析

#Splunk

#Windows

酒井剛

2024.04.24

SIEM を使ったユースケース紹介のブログとなります。
セキュリティ強化のために、ログは保存しているが、うまく活用できていない方は多いのではないでしょうか。
また、SIEMを導入したが、実際どんなログをとって何を見たら良いか分からず、活用しきれていないと感じていたりしませんでしょうか。

今回はセキュリティ観点で、重要度が高いとされるエンドポイントのログ、またよく使われている Windows OS の Windows Event Log のユースケースを紹介します。

Windows Event Log の不審なイベントを検知する

以下のようなイベントログのサービスを停止するようなアクションや、イベントログ自体を消すアクションに焦点を当てました。

Event ID	イベントログタイプ	説明
104	System	System ログファイルが消去されました
1100	Security	イベントログサービスが停止されました
1102	Security	イベントログが消去されました

これらのイベントは、悪用された場合、ランサムウェアの一連の攻撃で見られたり、侵入の痕跡を消すためにロギング自体を削除・停止したときに発生します。
MITRE ATT&CK では T1070.001 （Defense Evasion: Indicator Removal）に該当し、検知を回避する戦術となっています。

Mitre の戦術マップで見ると下の図のところですね。

まずは、これらのイベントが正しく収集され、分析できる状態になっていることが重要です。
Windows Event Log は通常、デフォルトでサービスが開始され、該当のイベントも出力されるようになっています。
注意点としては、Windows Event Log のローカルへの保存サイズは非常に小さいキャパシティ設定となっているため、SIEM 製品のエージェントなどをインストールし、リアルタイムに転送されるような仕組みをとっておくことが望ましいです。
SIEMなどの堅牢で十分なログ保持期間を持つツールに転送できない場合は、ローカルに保存するログ容量を増やしたり、ログの自動アーカイブを有効にすることが必要です。

ログのサイズなどは、こちらのベストプラクティスなどを参考にするのも良いかと思います。

Splunk で検知してみる

SIEM製品にログ連携した場合、実際にどのようなクエリを書いて検知すればよいか、Splunkを使って試していきます。

Splunkの場合、最初にログのフィールド抽出ルールやログタイプの定義を簡単に行うための Add-on と呼ばれる拡張機能をインストールするのが効率的です。
環境は Splunk Cloud でやっていきます。

Windows Event Log については、Splunk Add-on for Microsoft Windowsという Add-on が用意されているので、こちらをインストールしていきます。

Add-on 等の拡張機能のインストールは非常に簡単で、コンソールUI上の、Apps の Find More Apps に進み、検索バーに「Windows」とタイプして検索して Splunk Add-on for Microsoft Windows をインストールをクリックするだけです。
これをインストールしておくことで、取り込んだログがフィールドとして解析され絞り込みや統計処理がやりやすくなります。

次にログデータを送信する方法について検討していきたいのですが、可能であれば Universal Forwarder（以降UFと記載）という軽量な Splunkエージェントを使ってログを送信するのが良いです。
Splunk Cloud に UF を使ってログを送信するやり方については、こちらのブログをご覧いただくと良いです。

先ほどの Add-on をインストールしている場合、UF で Windows Event Log が送信されてくると、自動的に「sourcetype」というメタフィールドが付与されて Splunk に取り込まれてきます。

下記でログを検索してデータが取り込まれていることを確認します。

sourcetype="WinEventLog"

さらに、イベントの詳細情報を展開すると、フィールドがきちんと認識されていることが分かります。
今回検知する不審なイベントに該当する Event ID（EventCode）などがフィールドとしてあることも確認しておきます。

検索クエリを検討していきます。
「sourcetype」や「index」でログを絞り、対象のイベントIDに絞ります。
Splunkのサーチ文では、一行目にキー・バリュー形式で空白で条件を続けた場合、AND条件で絞り込みを行います。
ORの条件にしたい時は明示的に OR を指定して条件を続けます。

sourcetype="WinEventLog" EventCode=104 OR EventCode=1100 OR EventCode=1102

統計処理としては、「ComputerName」と「EventCode」、「Message」でグルーピングし、集計とログの発生している時間幅を見えるようにしておきます。
時間がepochタイムになっているので、フォーマットします。

sourcetype="WinEventLog" EventCode=104 OR EventCode=1100 OR EventCode=1102
| stats count min(_time) AS firstTime max(_time) AS lastTime BY ComputerName EventCode Message
| convert timeformat="%Y-%m-%dT%H:%M:%S" ctime(firstTime) 
| convert timeformat="%Y-%m-%dT%H:%M:%S" ctime(lastTime)

これで検索してみると、収集したログに実際にそのイベントが出力されていない場合、検索条件にヒットしないので何も表示されません。
そういう時、Splunkでは、Attack Data というものが用意されていて、Mitre ATT&CK などの攻撃戦術に該当する攻撃をシミュレートしたログセットがダウンロードすることができます。
今回の検知は、Mitre の T1070.001 に該当しているため、GithubのDatasetsをたどっていき、windows-security.logのサンプルをダウンロードします。

その後、Splunk Cloud の Add Data からログファイルをアップロードします。

Source Typeの設定で、「WinEventLog」 と入力し、その他はデフォルトの設定で取り込みを行います。

取り込みが正常にできたら、先ほど作ったクエリ文で検索してみます。
「Message」のフィールドだけ「The」とだけしか表示されておらず、フィールドの分割が正しく認識できていないようですが、一時的にアップロードしたデータなので特に問題ありません。（UF で取り込んだログのフィールドが全て正しく認識されていれば問題ありません。）